<?php
/**
 * OrderStatusManager class file.
 * @version 2011.09.19
 * @author lsx
 */

/**
 * OrderStatusManager类表示订单状态点对象管理器,负责按一定方式组织管理客户端指定的订单状态点对象序列.
 * 该类还提供了可供直接创建状态点对象的方法.
 * 
 * @todo 问题是该类最终要如何处理收集的订单状态点?如果收集的订单状态点只是直接按某序列使用,那么这个管理
 * 类就是多余的.
 * 分析:客户端业务需求是决定订单状态点对象的有无以及如何按何种序列使用它们的根本动力,那么这里的管理其就显
 * 得很多余,因为它不应该也无法完全反应客户端对订单管理的所有需求,或者,使用这样一种工具类来表达抽象业务需求
 * 是错误的.
 * 相比之下,订单状态点类{@see OrderStatus}则的定义则是正确的,因为它已经原子化到可以完全独立于客户端应用
 * 业务逻辑,而可以作为一个足够小的单元类被使用,且基本不会随客户端应用需求更改而变化.
 * 综上,不应该将客户端变化不定的需求逻辑放在具体的工具类中,而应该将它们留在客户端根据实际应用解决,作为工具类,
 * 只需要能够在被客户端反复使用的情况下都能满足需求就够了.
 */
class OrderStatusManger
{
	// 错误的管理类,错在用工具类来表达抽象业务需求.
}

class OrderStatusStream
{
	
}

/**
 * 状态点的排列组合结果:
 * 提交->取消
 * 提交->无效
 * 提交->通过(等待发货)->已发货(等待收货)->收货确认(交易完成)
 * 提交->通过(等待付款)->已付款(等待发货)->收货确认(交易完成)
 * 提交->通过(等待付款)->已付款(正在备货)->可取货(等待取货)->取货确认(交易完成)
 * 
 * 提交->通过(等待付款,已提交付款确认)->已付款(等待发货)->收货确认(交易完成)
 * 提交->通过(等待付款,付款确认无效)->已付款(等待发货)->收货确认(交易完成)
 * 
 * 决定状态文本的因素:
 * 状态值: 决定订单类型.
 * 订单类型: 决定订单状态流序列.
 * 订单状态流序列：体现了订单状态语义.
 * 客户端对订单状态语义的定义依赖于订单状态值的体现.
 * 
 * 订单状态的语义:
 * 订单操作者(顾客或者管理员对订单执行了某项操作,为了记录该项操作,必须为其分配唯一标识.
 * 此标识可以是任何能够被解析为具有实际语义的值,即此表示值仅仅是语义的载体,只要在反映给用户后用户能够很好地理解就行.
 * 一般,最好理解的是用户的母语,所以可以直接将此标识值保存为能够代表此项操作的母语字符串.
 * 如果为了满足国际化需求,让不同母语的人也能使用此应该,则可以将此标识做法进行改进.改进的方法是,用仅程序员和程序能够理解的数据作为标志值,
 * 在呈现给不同母语的用户时使用翻译程序进行相应呈现,这样就将程序内部实现逻辑和程序外部语义得到平衡和统一.
 * 为了反映用户的操作可以使用以下两种方式来标识：
 * (1)用同一个标识值代表多个操作,而仅将标识文本修改为用户期望看到的内容.
 * (2)每一个操作都使用唯一标识值表示,相应的其标识文本也是唯一的.
 * 以上两种方式都是可行的,但是方式(1)违反了最小原子原则,而方式(2)则满足.最小原子原则要求代表最小概念的原子实体不可再分而且语义明确,唯一且可区分.
 * 这里的最小原子应该定义为用户对订单的每一个操作,要将标识值和该值对应的文本视为原子的整体,而不应该让唯一的值有不同的文本,因为此文本和值都是为了
 * 唯一表现用户的这一操作语义,只是它们的载体不同,一个是只有程序员和应用程序可以理解的格式,另一种则是普通人可以理解的语言文字.
 * 为此,应该采用方式(2),对每个新增的操作定义新的唯一标识值和对应文本.
 */
?>